Configure OVN SB direct IPs for DCN nodesets #1186
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/a4d319b24b8342a787b83d63227f4077 ✔️ noop SUCCESS in 0s |
|
This PR is stale because it has been for over 15 days with no activity. |
fultonj
force-pushed
the
dcn_adoption_pr_ovn_sb
branch
from
9635e47 to
3238e07
Compare
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/23a15a66fd964088a5c0e4c21ae73ca1 ✔️ noop SUCCESS in 0s |
Problem: DCN compute nodes' OVN Controller agents cannot connect to the OVN SB database because the default ovncontroller-config ConfigMap uses Kubernetes ClusterIP (tcp:ovsdbserver-sb.openstack.svc:6642) which is not routable from external EDPM nodes on different network segments. While DNS resolution works (via dnsmasq at 192.168.122.80), the resolved ClusterIP cannot be reached from DCN sites which are on different internalapi subnets (172.17.10.x for dcn1, 172.17.20.x for dcn2 vs central's 172.17.0.x). This causes port binding failures when launching VMs in DCN availability zones: "Binding failed for port, please check neutron logs for more information" Evidence: - Central compute OVN Controller agents: Connected and working (`:-)` status) - DCN compute OVN Controller agents: NOT registered in OVN SB database - `ovn-sbctl show` shows only central computes and gateway, no DCN chassis Root Cause: Setting edpm_ovn_dbs variable is insufficient because the edpm_ovn role loads ovncontroller-config ConfigMap data which overrides the ovn-remote setting. The default ConfigMap (created by OVNDBCluster operator) uses ClusterIP. Solution: 1. Retrieve OVN SB internalapi IPs from pod annotations 2. Create DCN-specific ConfigMap (ovncontroller-config-dcn) with direct IPs 3. Create DCN-specific DataPlaneService (ovn-dcn) referencing this ConfigMap 4. Patch dcn1/dcn2 nodesets to use ovn-dcn service instead of ovn This ensures DCN nodes connect to OVN SB via routable internalapi IPs: tcp:172.17.0.34:6642,tcp:172.17.0.36:6642,tcp:172.17.0.35:6642 Co-Authored-By: Claude <[email protected]> Signed-off-by: John Fulton <[email protected]>
fultonj
force-pushed
the
dcn_adoption_pr_ovn_sb
branch
from
3238e07 to
1c8bf1d
Compare
fultonj
changed the title
fultonj
requested review from
abays,
jistr and
olliewalsh
and removed request for
abays
1 participant
Problem:
DCN compute nodes' OVN Controller agents cannot connect to the OVN SB database
because the default ovncontroller-config ConfigMap uses Kubernetes ClusterIP
(tcp:ovsdbserver-sb.openstack.svc:6642) which is not routable from external
EDPM nodes on different network segments.
While DNS resolution works (via dnsmasq at 192.168.122.80), the resolved
ClusterIP cannot be reached from DCN sites which are on different internalapi
subnets (172.17.10.x for dcn1, 172.17.20.x for dcn2 vs central's 172.17.0.x).
This causes port binding failures when launching VMs in DCN availability zones:
"Binding failed for port, please check neutron logs for more information"
Evidence:
:-)status)ovn-sbctl showshows only central computes and gateway, no DCN chassisRoot Cause:
Setting edpm_ovn_dbs variable is insufficient because the edpm_ovn role loads
ovncontroller-config ConfigMap data which overrides the ovn-remote setting.
The default ConfigMap (created by OVNDBCluster operator) uses ClusterIP.
Solution:
This ensures DCN nodes connect to OVN SB via routable internalapi IPs:
tcp:172.17.0.34:6642,tcp:172.17.0.36:6642,tcp:172.17.0.35:6642
Co-Authored-By: Claude [email protected]
Signed-off-by: John Fulton [email protected]